﻿<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" CodeBehind="GuidePage1.aspx.cs" Inherits="InstanceConfigurer.GuidePage1" %>
<asp:Content ID="Content1" ContentPlaceHolderID="HeadContent" runat="server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <h2>
        Guide Page 1</h2>
				<a href="GuidePage2.aspx">Guide Page 2 - Instance Controller Initial Setup</a><br />

	<p><strong>Instance Controller Operation:</strong></p>
	<p>The primary goal of the Instance Controller is to provide an appropriate number 
		of server instances to adeqately supply the requests of users while limiting 
		cost of operation.</p>
	<p>The central problem for the Instance Controller (IC) is to determine <strong>when</strong> 
		to raise or lower the count of instances.&nbsp; Ideally the IC would &quot;quickly&quot; 
		spot an increase in demand and bring on new instances in response to the demand.&nbsp; 
		This is called &quot;Attack Time&quot;.&nbsp; Again, ideally the IC would rapidly start 
		new instances in response to short interval high-demand swings.&nbsp; This is 
		accomplished through a <em>sampling time window</em> where the IC looks at a 
		group of performance counters for a given period of time, eg. a 30 minute 
		window.&nbsp; The wider the window the slower the IC reacts to change in demand.</p>
	<p>The Azure fabric severly dampens the fast attack ability because the time to 
		instance a new server is approximately 10 to 15 minutes.&nbsp; Any attempt to 
		react inside Azure fabric window time frame will result in over capacity and higher 
		costs.</p>
	<p>The IC attempts to react quickly to add new instances and then imposes a &quot;spin-up 
		delay&quot; time interval to allow the system to reevaluate for a period of time 
		after the new instances are running.&nbsp; If demand remains high then new 
		additional instances will be started until there is no further benefit.&nbsp; 
		The &quot;wind-down&quot; follows the same strategy except that it recognizes that each 
		instance is billed on a per hour basis. So there is lots of latency in the 
		wind-down.</p>
	<p><strong>How the Instance Controller Works:<br />
		</strong>The concept of controlling instances begins with the application that 
		needs to scale.&nbsp; That application must be configured to capture Azure 
		diagnostic data and must have minimal understanding of the Instance Controller 
		making it &quot;aware&quot; of instance control.&nbsp; The application is passive 
		otherwise with respect to diagnostic data capture.&nbsp; It should be understood 
		that configuration of the datapoints of interest and timing intervals is set 
		from the point of view of the working application&#39;s needs.&nbsp; <strong>The 
		question to keep in mind when configuring is, &quot;What is the desired result for 
		this application?&quot;</strong>&nbsp; The IC should help achieve this end.</p>
	<p>Once the working application is setup to capture diagnostics and IC configuration 
		is complete the IC will begin its duties.&nbsp; Generally the IC periodically 
		checks the configuration for changes, runs it evaluation of datapoints, and 
		takes any action necessary.</p>
	<p>The IC runs an endless loop with programmable sleep cycles in each loop.&nbsp; On 
		the first program scan the IC loads and initializes the configuration from 
		pre-defined default values and enters an inactive state.&nbsp; It then begins 
		its program scans which includes the sleep cycle.&nbsp; Subsequently if/when the 
		configuration is completely setup and the IsActive switch is set to true the IC 
		enters the active state.&nbsp; It will remain in active state until the 
		configuration is removed.</p>
	<p>Once running the IC cycles through its program scans.&nbsp; When it wakes for a 
		sleep cycle it queries the configuration table for the current configuration.&nbsp; 
		This allows the IC to pick up any changes in configuration.&nbsp; It checks the 
		mode of operation switch (auto/manual) and processes down the selected path.</p>
	<p><strong>Manual Mode:<br />
		</strong>This mode is as expected.&nbsp; Operators set a fixed number of 
		instances and the IC takes the action to either raise or lower the number of 
		instances to the desired amount.&nbsp; The IC will make no additional changes 
		while in manual mode.<br />
		Note: It is possible to use the Azure portal to manually change the instances 
		count while the IC is in auto mode.&nbsp; This has intersting side-effects that 
		can be very desirable.&nbsp; For example, suppose you want to handle a known 
		heavy load but want the IC to automatically take it back to a normal state.&nbsp; 
		By setting the decrement step size and the spin-up delay you could have the IC 
		precidtably bring the count back to normal over a period of time.</p>
	<p><strong>Auto Mode:<br />
		</strong>There are a large number of variable at play in the auto mode.&nbsp; 
		The variables can be grouped into: access, time intervals, datapoints, ranges, 
		and controls.&nbsp; Access variables contain account and application data that 
		allows the IC to access application account resources.&nbsp; Time intervals are 
		set-points that are used for triggers and for time-laspe datapoint collection.&nbsp; 
		Datapoints are actual response data collected by the Azure diagnostics.&nbsp; 
		Datapoints are also defined triggers used in the evaluation processes.&nbsp; 
		Ranges are paired&nbsp; datapoints.&nbsp; Controls are hard-stops such as 
		MaxInstances.</p>
	<p><strong>General Configuration Concepts:<br />
		</strong><em>Diagnostic Data:</em> The collection of data by Azure is in and of 
		itself a set of datapoints that insturct Azure fabric on which data to collect, 
		how often to sample, and when and where to store the collected data (plus some 
		filters to include/exclude spurious data items.)&nbsp; <strong>Warning</strong>: 
		Collection of diagnostics consumes resources and thus affects the performance 
		metrics.&nbsp; In the discussion above we introduced the notion that the 
		application drives the process of collection.&nbsp; The IC only evaluates points 
		of interest&nbsp; to the application.&nbsp; It is entirely possible to collect 
		too much data.</p>
	<p><em>Program Scans:</em> Program scans are intervals at which the IC wakes from it 
		sleep cycle and process the data evaluation.&nbsp; The evaluation process 
		generally takes no more than a single second.&nbsp; Thus for most of the time 
		when there is no action to be taken the IC will sleep for the programmed 
		interval, process for a second and the go back to sleep.<br />
		When the IC starts an action the program scan is inhibited until the action 
		completes or times out in the Azure fabric.&nbsp; Additionally the program scan 
		does continue after the action completes but in an idle state to maintain data 
		in a current state.&nbsp; While in idle state the IC is prevented from taking 
		further actions until the spin-up delay (15 to 30 minutes) ends.&nbsp; This idle 
		state allows time for the changes in instances available to have a measurable 
		impact on the data.&nbsp; It also dampens oscillations in the Azure fabric and 
		it prevents the IC from trying to start of stop instances before the current 
		actions are complete.</p>
	<p>Hint: Time intervals are very interdependent, start out by making intervals as 
		long as possible.</p>
</asp:Content>
